Digital Certificates are used all over the Secure Internet world for Authentication and Data Integrity. To set up a secure Web Server, the servers request a certificate from Certification Authorities (CA). CAs are trusted third parties that are recognized and trusted by all Internet population including all Web Servers and Web Browsers. The Server Certificate is a signature by the CA that the Server has been validated by it and can be trusted. It is a signature by the CAs private key on the server's public key, its Domain Name and other information like Address etc. The self-signed Certificates of the CAs are provided in all the Servers and Browsers. So in a normal SSL Handshake between a web server and a client i.e. a Browser, when the server presents its certificate to the browser the Browser software validates the Certificate by checking the signature of the CA on the certificate with the help of the CA certificate it has.
The Problem in the above digital certificates is that the strength of the security lies in the strength of the keys used in the system. There are one pair of keys for each entity including the CA and the Web Server—the Private Key and the Public Key. Now as the CA certificates are available publicly and trusted by everyone, these keys need to be very strong and no one should be able to break them. However, this is not possible forever. Knowing the Public Key (available in the CA Certificate), with some time and money, the keys be broken. Each key has its own lifetime alter which it is assumed that it is no longer safe to use the as in that time period the keys can be broken. So the CAs expire their certificates alter some amount of time. This poses some problems as the servers using the Certificates from CAs whose certiticates expire become no longer valid (even though the servers certificates are valid i.e. not expired). Although the communication might still be secure the client throws up a message box to the user warning him that the CA has expired and it might not be a safe to transact with the server. This creates a lot of confusion for the user.
The first solution to the above problem currently is to get a new certificate for the Web server from the CA with the new CA keys generated.
The second solution to the above problem is to modify the browser software to automatically accept this connection even though the certificate has expired.
This problem was seen on 1 Jan. 2000 very much as one of the most used Verisign Certificate expired on the day and Sites using the certificates issued by the CA has to face problems as their users got an undesired pop up window from Browsers warning them of the expiration. The solution was either get the new Server Certificate from Verisign or use New versions of the Browsers. The new versions probably accepted the certificate irrespective of the date expiration. As there are a lot of CAs, each will have the same problem when their certificates expire. The users will have problems with the old versions of the Browsers, which might amount to a sizable amount of a Web Site's users. Verisign had advised users to get the newer versions of the browser.
The third solution would be to have a requirement for all CAs not to issue Certificates for period spanning more than their expiry date.
The problem with the first Solution is that it requires generating of a new Server Certiticate Request, Sending it to the CA, the CA validating and signing it, sending the Certificate to the server, and finally the server importing it and making it the default Certificate. This amounts to a lot of rework, in fact requires the entire process of Certificate generation to be done again.
The problem with the second solution is that it will work only with the newer versions of the Browser software thereby cutting a sizable amount of the Internet Population. Generally while dealing with Internet applications, users would not like to spend much time in downloading new software or might not like being advised of getting a new Browser. So sites might lose on some of their customers and hence some of their Business. Secondly, by accepting the expired CA, the newer versions defeat the purpose of having expired the Certificate at the first place and do pose a security threat.
The problem with the third solution is that it is practically not feasible and is not used currently. There are a lot of situations where CAs have to issue certificates for longer times. For e.g., the CA might generate keys for 2 years, after 1 year and 1 month, when an entity requests for a certificate for 1 year, the CA has to issue it for 1 year and cannot do that for 11 months and expect the user to get it reissued after that. The user will go to some other CA and the CA will lose its business.